This invention relates to servers for computer network systems. More particularly, this invention relates to a server architecture that implements a dynamic content method for generating client responses.
A computer network system has one or more host network servers connected to serve data to one or more client computers over a network. FIG. 1 shows a simple computer network system 20 with a single host network server 22 connected to serve data to a client 24 via a network 26. The client 24 sends a request for data and/or services to the server 22 over the network 26. The server 22 processes the request and returns a response over the network 26. If the request is for data, the server 22 accesses a database 28 to retrieve the requested data 30 and returns the data 30 as part of the response.
The client-server system 20 is representative of many different environments. One particular environment of interest is the Internet. The server 22 runs a Web server software program that accepts requests from client-based programs (e.g., browsers) and returns data 30 in the form of Web pages or documents to the client 24. The Web pages are commonly written in HTML (hypertext markup language) and XML (extensible markup language). Web pages are transmitted using conventional network protocols, such as TCP/IP (Transmission Control Protocol/Internet Protocol), HTTP (Hypertext Transfer Protocol) and DCOM (Distributed Component Object Model). The client 24 executes a browser or application to render the Web page into human-perceptible forms. A Web document might include text, images, sound, video, active code, and so forth.
Documents served from a server to client are typically generated using either or both of two methods: a static content method and a dynamic content method. In a static content method, the document is created in advance and stored statically on a server database. When a client requests the document, the server retrieves the document and transmits it over the network to the client. FIG. 1 is an example in which the server retrieves the static data 30 from database 28 and serves the data to the client 24. It is further noted that conventional servers, and particularly Web servers, may be configured to push the content to the client without receiving a request. The static content method has an advantage of minimizing the user""s perceived response time, meaning the time between requesting the document and seeing it rendered on a computer screen. It has a disadvantage that all users who request the document receive exactly the same content. With static content, the server cannot respond to specific user requests or personalize a document for individual users.
In a dynamic content method, the document is generated dynamically by the server. When a client requests a document, the server invokes one or more agents, feeding the agents relevant parameters from the user""s request (such as the user""s name). The agent(s) generate the document that satisfies the user""s request and the server returns the document over the network to the client. The dynamic content method has the advantage of responding to specific user requests or personalizing content for individual users. It has the disadvantage that the user""s perceived response time will generally be longer than with static document requests. This is because the document generation process involves additional time to invoke the appropriate agent(s) and generate the document.
The server generates dynamic content documents by invoking an agent in one of two ways: an xe2x80x9cout-of-processxe2x80x9d method and an xe2x80x9cin-processxe2x80x9d method. In an xe2x80x9cout-of-processxe2x80x9d method, the agent runs in its own process and address space, separate from the server""s process and address space. Typically, the out-of-process method uses the industry-standard common gateway interface (CGI) as the communication mechanism between the server and agent. CGI is described in a publicly available document on the Web at http://hoohoo.ncsa.uiuc.edu/cgi. In an xe2x80x9cin-processxe2x80x9d method, the agent runs within the Web server""s process and address space. The in-process method typically uses a vendor-specific application programming interface, like the Internet Server Application Programming Interface (ISAPI) implemented by Internet Information Server (IIS), which is available from Microsoft Corporation. The ISAPI technology is described in more detail in a document at http://www.microsoft.com/iis/Support/iishelp/iis/misc/documentation.asp.
To illustrate the two dynamic content methods and how they can be used in conjunction with the static content method, consider a scenario in which the server 22 runs a Web server for an online retail company. When the client 24 first accesses the Web site, the server 22 might retrieve a pre-existing home page for the company from the database 28 and serve that page to the client 24. This initial step is an example of a static content method. From the home page, the client might request to view an online catalog of products offered by the company. In response, the Web server might invoke a catalog agent to guide the user through various product offerings. When the user decides to purchase a product, the client submits an order request. In response, the Web server might invoke an order agent to assist the user in ordering the product. The steps involved with actively serving a catalog or taking an order are examples of dynamic content methods. They both involve dynamic generation of documents in response to input received from the client.
FIG. 2 shows an xe2x80x9cout-of-processxe2x80x9d method under this scenario. The server 22 runs a Web server 40 as process 1. The Web server 40 handles the incoming requests from the client. When the client first hits the Web site, the Web server 40 retrieves the company""s home page 42 from the database 28 and transmits the home page 42 to the client. When the client sends an order request, the Web server 40 initiates an order manager 44 to assist the user with ordering the desired product or service. The order manager 44 is initiated using the CGI technology as a second process 2, which uses a separate process and address space than process 1, as represented by the dashed lines.
When the user selects an item, the order manager 44 dynamically generates an order document 46 that contains the user""s name, a description of the selected item, the cost of the item, and payment terms. The order manager 44 returns the order document 46 to the Web server 40, which then serves the document 46 to the client. Afterwards, the order manager 44 is terminated and the second process 2 is halted.
The out-of-process method shown in FIG. 2 has an advantage in crash prevention and recovery. If the out-of-process order manager 44 is unreliable and ultimately crashes, it will not cause the Web server 40 to crash. However, the out-of-process method has a disadvantage in that a particular agent must be loaded into memory each time a request arrives for it. Using CGI technology, the agent must also be unloaded from memory once it finishes the request. This loading and unloading consumes resources, resulting in a relatively slow response time. Another problem compounding the slowness is that the out-of-process method involves cross-process communication between processes 1 and 2, including such activities as marshalling, messaging, and the like.
A variation of CGI, known as FastCGI, allows the server to keep the agent loaded, rather than terminating the agent each time it responds to a particular request. FastCGI is an improvement over CGI in that it saves the per-request invocation overhead, thereby improving the response time. However, the FastCGI is still run in a separate process, and hence the drawbacks associated with cross-process communication remain. A more detailed discussion of FastCGI is found at http://www.fastcgi.com/kit/doc/fastcgi-whitepaper/fastcgi.htm.
FIG. 3 shows an xe2x80x9cin-processxe2x80x9d method under the same scenario of the online retail company. In this case, when the client sends an order request, the Web server 40 initiates an order manager 48 to assist the user with ordering the desired product or service. The order manager 48 is initiated using the ISAPI technology to run within the same process 1 as the Web server 40. That is, the Web server 40 and the order manager 48 use the same process and address space designated by the server. When the user selects an item from the online catalog, the order manager 48 dynamically generates an order document 50 that contains the user""s name, a description of the selected item, the cost of the item, and payment terms. The order manager 48 returns the order document 50 to the Web server 40, which then serves the document 46 to the client. The order manager 48 can remain loaded for other requests, or terminated when desired.
The in-process method is advantageous in that a particular agent need only be loaded into memory once, when the first request arrives for it. The agent can then remain in memory within the server""s process and address space, and can handle additional requests that arrive for it. The in-process method has a further advantage in that there is no need for cross-process communication. As a result, the in-process method is comparatively faster than the out-of-process method. However, the in-process method has the disadvantage that if the agent is unstable and crashes, it will cause the server to crash too.
Most large Web sites and many smaller ones deliver one or more applications in the traditional information system sense. A site that supports catalog shopping, library browsing or database access will typically consist of many separate agents and documents that together implement the site""s xe2x80x9capplicationxe2x80x9d; in other words, the unified experience presented by the Web site to the user. The developer of such a site needs a mechanism to organize an application""s software components to enforce consistency, compatibility, version control, and other requirements across components. It is also desirable to construct high performing agents because they often provide the most appealing content delivered by the Web site. The agents are often required to process more than their proportionate share of user requests. Agents that perform slowly may cause users to abandon a Web site because they become frustrated with slow response times, no matter how appealing the content might be.
A Web site developer is also interested in protecting the site against system or process crashes. A Web server can host many Web applications. The applications may be hastily developed and, while effective at certain tasks, may perform unpredictably when subjected to high volume or wide variety of user requests at an active Web site. If not guarded against, such unpredictable applications may bring down the entire site. Accordingly, a developer would like to be able to isolate xe2x80x9ctrustedxe2x80x9d components (i.e. components that are fully tested, debugged, and judged to be crash proof in normal operation) from non-trusted components.
Another advantage of isolated application is that you can stop and unload application components from memory without interfering with the operation of the Web site. Stopping an isolated application is extremely convenient way to install new components because you don""t have to stop and restart the web server to stop and restart an application.
Accordingly, there is a need in the industry to further improve the dynamic content methods for serving documents and other data to clients. There is a need to develop an architecture which enables Web site developers to create high performing agents, to organize the agents in functional groups for optimal performance at a given Web site, and to design isolation between the trusted agents and the non-trusted agents.
This invention concerns a server architecture that enables isolation of non-trusted agents, which are run out-of-process, and the ability to detect and recover failed out-of-process agents. The server architecture provides a managerial hierarchy to manage the agents and to control how the client requests are handled. An application manager manages each collection of agents. The agents within the associated collection are independent from, but dynamically accessible by, the application manager. Depending on the request, the application manager selects one or more agents to generate content to be returned to the client. In this manner, the application manager and associated agents under its control form an application for processing client requests. In a Web environment, for example, an application designed for an online retail company might be configured as a catalog application, or an ordering application, or a customer service application, and so forth.
An application manager director manages the application managers. The application managers are independent from, but dynamically accessible by, the application manager director. Depending on the request, the director selects the appropriate application manager to handle the request, which in turn selects the appropriate agent to process the request. According to the managerial hierarchy, the director first decides which server application is best suited to handle the incoming request, and then the application manager within the chosen server application decides which specific agent should process the request.
The director can be implemented as part of the general server software. The separate server applications (i.e., the agents and associated application managers) can be run either in-process or out-of-process with the server software. An in-process application offers higher performance at the risk of crashing the system if one agent performs unreliably. An out-of-process application affords high reliability and crash protection at the expense of lower performance due to cross-process communication.
The server architecture has a detection and recovery subsystem that detects when an out-of-process application crashes and then recovers the application from that crash. The subsystem logs requests when they are passed to the out-of-process application, and removes the requests from the log when responses to the requests are returned from the application. If the out-of-process application crashes while one or more requests are outstanding, those requests remain listed on the log and thus readily identifiable. During recovery, the subsystem cleans up the outstanding requests until the log is cleared. Thereafter, the subsystem restarts the failed application to restore the service.